1. Field of the Invention
The present invention relates to policy control within a communications network and in particular, though not necessarily, to policy control at a GGSN of a mobile telecommunications network.
2. Background to the Invention
The European telecommunications institute known as 3GPP is currently in the process of introducing a new set of protocols for the mobile telecommunications system known as Universal Mobile Telecommunications System (UMTS). The architecture of a UMTS network is based upon a UMTS core network and a UMTS Terrestrial Radio Access Network (UTRAN). For the transfer of data, UMTS will implement a packet switched service such as General Packet Radio Service (GPRS) or similar. In order to send and receive data, a mobile terminal or User Equipment (UE) establishes a “session” with a node in the network known as a Gateway GPRS Support Node (GGSN). The GGSN provides an interface for the UE to the outside world.
Within the core network, the GGSN enforces policies (i. e. control options) of the network operator. For example, an operator may define policies setting out which subscribers can access which data services (i. e. the blocking and unblocking of services), and allocating priorities to subscribers, e. g. at which times subscribers can connect.
To facilitate the provision of multimedia services, 3GPP has been developing a so called IP Multimedia Core Network Subsystem (IMS). The IMS communicates with the GPRS network and contains all elements that are used to provide IP based multimedia services. For a mobile to mobile call, the IMS will sit between two GPRS networks (assuming the mobiles belong to different networks). Certain nodes of the IMS may be owned by the operator of a first of the GPRS networks, with the remaining nodes being owned by the operator of the second network (some IMS nodes may be owned by a third party). The base protocol for multimedia services is the IETF Session Initiation Protocol (SIP). SIP makes it possible for a calling party to establish a session with called party (over which data may be exchanged) even though the calling party does not know the current IP address of the called party, prior to initiating the call. SIP provides other functionality including the negotiation of session parameters (e. g. Quality of Service and codecs).
The IMS comprises a Serving Call State Control Function (S-CSCF) which performs the session control services for the UE, and maintains a session state as needed by the network operator for support of services. The main function performed by the S-CSCF during a session is the routing of incoming and outgoing call set-up requests. The IMS may also comprises a Proxy CSCF (P-CSCF). The main function performed by the PCSCF is to route SIP messages between the UE and the home network. The P-CSCF communicates with the GGSN.
FIG. 1 illustrates schematically a typical scenario where User Equipment (UE) 1 is a subscriber of a cellular telephone network 2. The subscriber using the UE 1 is identified in the network 2 by a unique subscriber identity, and the network is referred to as the subscriber's “home” network. In the scenario illustrated in FIG. 1, the UE 1 is registered with a “foreign” or visited network 3. The visited network comprises a General Packet Radio Service (GPRS) network 4 (as well as a circuit switched network which is not illustrated in FIG. 1). Within the network 4, two nodes relevant to the UE 1 can be identified. These are the Serving GPRS Support node (SGSN) 5 and the Gateway GPRS Support Node (GGSN) 6. The role of the SGSN 5 is to maintain subscription data (identities and addresses) and to track the location of the UE within the network. The role of the GGSN 6 is to maintain subscription information and allocated IP addresses and to track the SGSN to which the UE 1 is attached. The GGSN 6 is coupled to an IP network.
Typically, when the UE 1 is turned on it “attaches” itself to the GGSN and a Packet Data Protocol context is established between the UE 1 and the GGSN 6. This context provides a “pipe” for transporting data from the UE 1 to the GGSN 6. This process involves the allocation of an IP address to the UE1. Typically, the routing prefix part of the address is a routing prefix allocated to the GGSN 6.
FIG. 1 illustrates a second UE 7 which is registered with a foreign network 8 and which has as its home network a network 9. Nodes and (sub) networks within the foreign network 8 are identified with like numerals to those used within network 3. The IP Multimedia Core Network Subsystem (IMS) contains all of the elements required to provide IP based multimedia services including the setting up of sessions between the two UEs 1,7. The functionality provided by the IMS is set out in 3GPP TS 23.228. The IMS consists of a set of nodes which are coupled to an IP backbone network. Illustrated within the IMS of FIG. 1 are a Proxy Call State Control Function (P-CSCF) node 10 in each of the visited networks 3,8. and a Serving Call State Control Function (S-CSCF) node 11 in each of the home networks 2,9. In order to establish a session between the two UEs 1,7 of FIG. 1, appropriate SIP signalling is sent from the P-CSCF located in the visited network to which the initiating party is connected, to the S-CSCF located in the initiating UE's home network. This S-CSCF then contacts the S-CSCF in the home network of the called UE, which in turn contacts the P-CSCF in the visited network to which the called UE is connected. A data session can then be established between the two GGSNs 6 to which the UEs 1,7 are connected. When a UE is registered with its home network, the S-CSCF of the home network serves also as a P-CSCF for the UE.
The Internet Engineering Task Force (IETF) has specified a protocol known as Common Open Policy Service (COPS) which is a simple query and response protocol that can be used to exchange policy information (which may relate to any feature, service, etc over which it is desired to exercise control) between a policy server (Policy Decision Point or PDP) and its clients (Policy Enforcement Points or PEPs). COPS is a query/response protocol that supports two common models for policy control: Outsourcing and Configuration.
In the outsourcing scenario, the PEP delegates responsibility to an external policy server (PDP) to make decisions on its behalf. For example, in COPS Usage for Resource reSerVation Protocol (COPS-RSVP), when a RSVP reservation message arrives, the PEP must decide whether to admit or reject the request. It can outsource this decision by sending a specific query to its PDP and, waiting for its decision before admitting the outstanding reservation. This is illustrated in FIG. 2.
The COPS configuration model addresses the kind of events at the PEP that require an instantaneous policy decision. This variation is known as COPS for Provisioning (COPS-PR). COPS-PR is designed as a means to install policies from the decision node into the enforcement node where the policy is enacted. With this protocol, decisions are transmitted asynchronously from the decision node at anytime, and the enforcement node replies to indicate whether the policy was installed or not. This is shown in FIG. 3. The PDP may proactively configure the PEP to react in some specified manner to external events (such as user input), PEP events, and any combination thereof (N: Mcorrelation). Configuring or provisioning may be performed in bulk (e. g., entire router QoS configuration) or in portions (e. g., updating a DiffServ marking filter).
COPS-PR is a general purpose protocol, and can be used to install policies for any functions. It uses the concept of a Policy Information Base (PIB). A PIB defines the policy data. There may be one or more PIBs for a given area of policy and different areas of policy may have different sets of PIBs. This allows support for a model that includes multiple PDPs controlling non-overlapping areas of policy on a single PEP.
A “client-type” (value) is used to identify the function that is being managed by the policy control. A single client-type for a given area of policy (e. g., DiffServ) will be used for all PIBs that exist in that area. The client will treat all of the COPS-PR client types it supports as non-overlapping and independent name spaces where instances are shared. For each client type which the PEP supports, the PEP can only work towards a single PDP.
3GPP has developed a mechanism for allowing the P-CSCF to control a function within the GGSN. The architecture for QoS management defined by 3GPP (recommendation 23.207) is illustrated in FIG. 4. As shown in this Figure, the GGSN (Gateway Node) communicates with a Policy Control Function (PCF) function which can be co-located with the P-CSCF. This interface between the GGSN and the PCF function within the PCSCF is specified as the Go interface. The Go interface is based on the COPS protocol.
It is noted that although the PCF element may be located external to the P-CSCF, the 3GPP standard allows for it to be co-located with the P-CSCF, and the protocols must therefore support operation in this configuration.